Tools such as `cibuildwheel` and
[`xbuild`](https://pypi.org/project/xbuild/) manage building wheels for
iOS by using a cross-platform virtual environment - a valid virtual
environment for the build platform that can "pretend" to be the
target/host platform when asked for sysconfigdata. This is done by
monkeypatching key values in the sys, sysconfig, platform and os module
when the interpreter starts. Many of these environments also set
`sys.cross_compiling = True` as an indicator that they aren't "real"
environments.

Maturin's concept of "cross-compiling", however, has more to do with
whether the interpreter that is running the Maturin build can be used to
interrogate details about the Python install for the purpose of
configuring a build. To that end, somewhat counterintuitively, a
cross-platform venv *isn't* "cross platform" from the perspective of
Maturin.

This PR makes 3 changes:
1. It marks iOS builds as *not* being cross-platform. This ensures that
the sysconfigdata values from the interpreter running maturin are passed
to the build
2. When the build has not been given an explicit `--target`, or
`--interpreter`, the build interpreter will be interrogated to see if it
is a cross-compilation environment - and if it is, the target implied by
the platform is used for the build.
3. When an explicit `--interpreter` *has* been provided, the target will
be modified if the environment is a cross-platform environment.

When combined with #2827, this means it is possible to create an iOS
wheel with no more than `maturin build`, provided you're in an iOS
cross-platform venv (such as those created by `cibuildwheel` and
`xbuild`).

At present, when targeting an `abi3` build, Maturin will use a dummy
interpreter to provide build configuration details, unless the user
specifies an interpreter with `--interpreter`, or the target is
cross-compiling, or Windows is being targeted.

The use of a dummy interpreter when a real interpreter is available can
lead to the interpreter details that are available and defined in
`sysconfigdata` not being used as part of the build process.

This was discovered in the process of working on iOS support (see #2827
and #2828); although the iOS build environment *does* provide build
configuration details, those details were not being passed down to the
PyO3 build configuration. With those two patches (and some patches to
PyO3 - see PyO3/pyo3#5605 and PyO3/pyo3#5606), it was possible to build
a non-abi3 wheel; but this patch was needed to build an abi3 wheel.

#2827 introduced PEP 730-compilant tags for iOS wheels. 

The PR description for that ticket correctly described the tags that
*should* exist; but due to the inconsistent naming of the Rust
`x86_64-apple-ios` *simulator* target, the implementation in #2827 would
produce wheels tagged `x86_64_iphoneos`.

This PR corrects that oversight.

#2827 introduced PEP 730-compilant tags for iOS wheels. 

The PR description for that ticket correctly described the tags that
*should* exist; but due to the inconsistent naming of the Rust
`x86_64-apple-ios` *simulator* target, the implementation in #2827 would
produce wheels tagged `x86_64_iphoneos`.

This PR corrects that oversight.